The disclosed embodiments of the present invention relate to partitioning a storage space of a storage device, and more particularly, to a method of creating a target storage layout table referenced for partitioning a storage space of a storage device (e.g., a flash device) and related electronic device and machine-readable medium.
Recently, handheld devices become more and more popular. Most of them aim at low price, small size, high computing power, and powerful functionality. Therefore, there is a need for an embedded operating system. For example, the Linux-based embedded system has some advantages such as no proprietary problem, high portability, and comparatively easy to be implemented. The Linux-based embedded system is usually a diskless system. In order to keep permanent data in the Linux-based embedded system, using a flash device as its disk system is a widely adopted strategy.
In general, a storage device may be partitioned into a plurality of partitions to facilitate the use of the storage device. Taking a Linux-based embedded system for example, a memory technology device (MTD) subsystem provides an abstract layer for raw flash devices, which makes it possible to use the same application programming interface (API) when working with flash devices of different flash types and technologies. The Linux-based embedded system is internally assigned a flash layout table referenced for partitioning an employed flash device (e.g., a NAND flash) into a plurality of partitions for different MTDs.
However, the flash device may have bad blocks scattered around the flash device when manufactured in the factory. For example, 80 bad blocks may be located anywhere in the flash device. However, there is no information available in the flash device for indicating the exact locations of these bad blocks scattered in the flash device after the flash device is manufactured and then shipped to the market. The conventional partitioning strategy has to consider the worst case when defining each partition in the flash device. Please refer to FIG. 1, which is a diagram illustrating a conventional flash layout table 100. The desired partitions PA, PB, PC, and PD originally required by the system have the sizes Size_A, Size_B, Size_C, and Size_D, respectively. As mentioned above, there are bad blocks scattered around the flash device, and the exact locations of these bad blocks are unknown after the manufactured flash device is shipped to the market. The conventional partitioning strategy therefore makes each actually used partition larger by having a reserved area included therein. As shown in FIG. 1, each of the reserved areas RSV_A, RSV_B, RSV_C, and RSV_D has the same size Size_R corresponding to an estimated maximum number of bad blocks scattered around the flash device. For example, each of the reserved areas RSV_A, RSV_B, RSV_C, and RSV_D contains at least 80 blocks. As a result, the flash layout table 100 defines four partitions PA′, PB′, PC′, and PD′ having the actual sizes Size_A+Size_R, Size_B+Size_R, Size_C+Size_R, and Size_D+Size_R, respectively. After the additional reserved areas are assigned to the partitions PA′-PD′, the remaining storage area with the size Size_R′ may act as a spare reserved area RSV_R of the flash device that can be used for other purposes such as data buffering.
Actually, some of the actual storage areas corresponding to the partitions PA′, PB′, PC′, and PD′ may have many bad blocks, and the remaining may have no bad block. Regarding an actual storage area corresponding to one of the partitions PA′, PB′, PC′, and PD′ that does not have bad blocks at all, the blocks included in the reserved area are not used, resulting in a waste of the storage space of the flash device. Moreover, as the partitions PA′-PD′ have reserved areas RSV_A-RSV_D included therein, the spare reserved area RSV_R which may be used for other purposes would be small due to limited storage capacity of the flash device. As a result, the flash device initialized using the conventional flash layout table 100 shown in FIG. 1 may lack flexibility in the use of the spare reserved area RSV_R. In a worst case, the flash device partitioned using the conventional partitioning strategy may have no remaining storage area available for acting as the aforementioned spare reserved area RSV_R. Regarding an application which is equipped with a storage device with small storage space, applying the conventional partitioning strategy to the storage device is impractical.